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1. Abstract 

The Virtual Environment Vehicle Interface (VEVI), devel- 
oped by the NASA Ames Research Center’s Intelligent 
Mechanisms Group, is a modular operator interface for 
direct teleoperation and supervisory control of robotic vehi- 
cles. 

Virtual environments enable the efficient display and visual- 
ization of complex data. This characteristic allows operators 
to perceive and control complex systems in a natural fashion, 
utilizing the highly-evolved human sensory system. 

VEVI utilizes real-time, interactive, 3D graphics and posi- 
tion / orientation sensors to produce a range of interface 
modalities from the flat panel (windowed or stereoscopic) 
screen displays to head mounted/head-tracking stereo dis- 
plays. The interface provides generic video control capabil- 
ity and has been used to control wheeled, legged, air bearing, 
and underwater vehicles in a variety of different environ- 
ments [1]. 

VEVI was designed and implemented to be modular, distrib- 
uted and easily operated through long-distance communica- 
tion links, using a communication paradigm called 
SYNERGY. 

2. Introduction 

2.1 Background 

Mission of the IMG 

The objective of the Intelligent Mechanisms (IM) group is 
the systems investigation of intelligent mechanisms. The 
research is focused by the task of building intelligent mecha- 
nisms, rather than being driven by a specific technological 
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bias. Pursuant to this focus we have concentrated on archi- 
tectures for intelligent mechanisms, including software 
architectures, advanced processors, sensor processing 
(including vision, tactile, and proximity sensors) and user 
interfaces [9]. 

Focus 

The application focus of this group is driven by the relative 
importance of this technology to NASA missions, in three 
specific areas: 

( 1) construction and exploration tasks on planetary surfaces. 

(2) low overhead operations for orbital missions. 

(3) using undersea vehicles as analogs of space vehicles. 

The products of the IM group are advancements in the ability 
to accomplish a NASA mission. 

Current Research 

Crucial to the success of intelligent mechanisms is suitable 
computational systems and methods for robustly evaluating 
and handling faults. Additionally, operational needs in 
unstructured or changing environments requires appropri- 
ately constructed systems architectures incorporating multi- 
ple sensor data, intelligent software and user interfacing. At 
this time, therefore, our work is directed towards: 

• Advanced computing incorporating high performance pro- 
cessing and software architectures. 

• Sensor processing using visual, tactile and proximity sen- 
sors. 

• User interfaces incorporating virtual environments and 
telepresence. 

• Systems integration of components into demonstrable 
applications. 

Facilities 

The IM laboratory is located in the Automation Sciences 
Research Facility (ASRF) at the NASA Ames Research Cen- 
ter (ARC). This facility houses the Computational Sciences 
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Division (Code IC). 

The majority of the Intelligent Mechanisms Group’s research 
is performed in the IM Laboratory at Ames Research Center. 
Additionally, the group conducts collaborative work with 
other ARC research groups and external organizations. The 
IM group currently has access to manipulator arms, mobile 
platforms, undersea vehicles, and high performance worksta- 
tions running various user interface environments. 

Computational Architecture 

In [1], we have described the computational architecture 
used to fulfill the requirements of our typical systems 
(ARC A: Ames Robotic Computational Architecture). 

In summary, the architecture provides solutions for the prob- 
lems linked to different issues: 

• Multiple data streams (sensory, command, knowledge) 
from multiple sources. 

• Need to deal with synchronous processing (common 
clock, regular execution, strict execution schedule), 
loosely-synchronous processing (similar to previous, but 
without tight synchronization), and asynchronous process- 
ing (event-driven or free-running processes without syn- 
chronization). 

• Multiple time delays (continuous to minutes). 

• Application specific processor thoughput requirements 
(0.5 MIPS - 500 GIPS). 

• Synchronization of communications between multiple 
modules (standardized communications). 

The present paper describes an approach to the implementa- 
tion of systems onto ARCA. 

3. Design 

3.1 Introduction 

This paper describes the version 3.0 of VEVI. Previous ver- 
sions have been used for a variety of tasks, though were 
implemented on a case-to-case basis, with application-spe- 
cific code. The primary motivation for the development of 
VEVI 3.0 was to simplify the maintenance of application- 
specific code, and also to provide a better platform for future 
developments. 

Past applications of VEVI include remote control of the fol- 
lowing different systems: 

• TROV (Telepresence Remotely Operated Vehicle) - an 
underwater vehicle remotely controlled from California to 
the Antarctic. 

• MEL (Mobile Exploration Landrover) - our mobile rover, 
operated and controlled locally. 

• Dante was a walking mechanism developed by Carnegie 
Mellon University, and remotely controlled from a site 
local to the volcano it was exploring, with sites over the 
country using VEVI to display telemetry information and 
terrain maps. 

• Marsokhod is a planetary rover prototype which has been 


operated remotely in the Mohave desert, the Kamchatka 
peninsula and in Moscow from California. 

Based on those wide cases, we came up with a clear under- 
standing of the requirements of most of the applications we 
are developing. 

3,2 Requirements 

3.2.1. Distribution 

In order to maintain a standardized base, from which exten- 
sions may be developed, we desired that version 3.0 be eas- 
ily customizable by end-users. At the same time, we wished 
to maintain interoperability by restricting access to the 
underlying structure. We therefore sought a design which 
would allow flexible customizing without a requirement for 
the kernel source code. 

3.2.2. Flexibility 

Based on the provided tools, a user must be able to interface 
with VEVI using an easy but extensible interface. Instead of 
provided access to the base tools, which would increase sys- 
tem complexity, we decided to follow an alternate approach, 
in which the user can extend the capability of the basic sys- 
tem, to fulfill any specific need. With this approach, the sys- 
tem remains simple but provides possibilities for further 
implementations. 

In a different case, the user might want to bypass the library 
of provided tools and use his own. This is made possible as 
an alternative. 

Finally, in previous versions, modifications were made to the 
software in order to adapt the system to different situations 
and vehicles. The new approach provides with a way to 
define the environment through configuration files, which 
allows much better flexibility and turn-around time between 
projects. 

3.2.3. Modularity 

In order to achieve the specified goal, it was necessary to uti- 
lize a very modular approach. Modularity is attained by uti- 
lizing an object oriented paradigm. Basically, every entity in 
the environment is viewed as an “object”. Object then can 
interact and communicate through messages. This event- 
driven approach provides us with a stateless system which 
allows add-ons and removal of parts of the system without 
destruction of the whole. Also, it allows separate develop- 
ment of modules, which then can be added to the core and 
provide additional capability, without touching the existing 
base. 

With this approach, a user can write an entire set of new 
objects, which will extend the system with needed specific 
functionality, without complicating the provided base capa- 
bilities. 

3.2.4. Standard communications 

Since our system is articulated around ARCA [11, and 
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includes a whole set of disparate platforms and computing 
architectures, which communicate through a backbone, it is 
clear that we needed to standardize somewhat the communi- 
cation protocols. 

Constraints linked to remotely operated vehicles (sometimes 
on a different continent, or planet), as well as the capability 
to be as close as possible of an existing standard made us 
choose to define communication tools based on the Internet 
Protocol (IP) as our standard. So far, we have used three 
existing networking tools based on an IP layer: TCA [2;3], 
TCX [4], TelRIP [5] and NDDS [6]. 

Although most of our past missions were conducted using 
one or more of those standards, it clearly showed that we 
need to have the capability to adapt to a number of those 
tools. 

External collaboration for past and future missions, as well 
as constraints linked to data rates and bandwidth are a deter- 
mining factor for the choice of one or the other standard. 

3.2.5. Execution speed 

Based on previous experience, it is necessary to maintain a 
frame rate at the Tenderer’s level that is greater than 10 
frames per second (fps). At lower frame rates, the user expe- 
riences significant loss of the immersion provided by Virtual 
Environments. 

To comply with such a tight constraint, especially on lower- 
end platforms, the rendering node will contain as little “intel- 
ligence”, or application-specific data and algorithms as pos- 
sible. Nodes hanging off the backbone (Internet) will be used 
in the cases where such knowledge is required and will com- 
municate directly with VEVI. 

Also, a VEVI might not reach the necessary frame-rate 
needed to efficiently process data sent at much higher rates. 
For this reason, we decided that an external process, known 
as CommTask, would be responsible for dealing with differ- 
ent data flows, buffering and queuing of data. Also, Com- 
mTask will be able to adjust the way it delivers messages, 
based on directives from VEVI directly. For example, VEVI 
might request CommTask to only send the most “urgent” 
message, not to send messages regarding one object, or to 
size down the number of messages made available at each 
polling session. 

3.2.6. Distributed environment 

One of the group’s goals is to develop technology which 
allows scientists and the public to access missions sites and 
data. Therefore, we want to have the possibility for people to 
interface with vehicles, tools and data gathered using their 
own low-cost platform at the office, or at home, throughout 
the country. 

We also want to be able to provide multiple people separated 
with the possibility to interface and collaborate through mul- 
tiple Virtual Environment with the remote vehicle. 


3.2.7. Portability 

In order to reach the previous goal, we need to have the pos- 
sibility to run the software and the main rendering tool on PC 
platforms, as well as high-end graphic machines. 

Links with the backbone will be created through alternate 
communication protocols (serial over a modem line, ISDN) 
through a translator which will convert data to the communi- 
cation protocol used on SYNERGY 1 . 

3.2.8. Data types 

Complex and mixed systems present two different kinds of 
data that we need to be able to deal with: 

• Streams: the data flows at any rate. Whomever is inter- 
ested in it will obtain the latest update and process it. 
Some updates may be lost, multiple updates may be 
received between lookups, the order is not important. Such 
message do not queue up in case the lookup rate is lower 
to the sending rate. 

• Sequences: the data is sent out in a particular order, which 
needs to be respected. Every message needs guaranteed 
delivery, in the right order. In this case, buffering and 
queuing become important issues, especially when the 
provider outputs information at a much higher rate than 
the consumer can process it. Sequences are typically 
higher-level commands, and therefore aren’t sent out at 
very high rates over an average period of time, but the 
need to process and store the information remains a prior- 
ity to handle a higher rates than usually provided by 
VEVI. 

The CommTask previously mentioned will be used to pro- 
cess the data and store it, independently of the frame rate of 
the rendering node. It will then deliver the information, 
based on its properties, as well as the requirements of VEVI, 
on every request. With this approach, all VEVI will have to 
do is simply collect whatever information is delivered, 
knowing that it correspond to previously defined require- 
ments. A great deal of computation is therefore avoided in 
the rendering node, thus allowing better frame rate in the 
Virtual Environment. 

3.3 Summary 

• Object-oriented approach 

• Messages between objects 

• Based on a IP backbone for communications 

• Rendering at > 10 fps 

• Configuration File 

• CommTask for buffering and conversion between vehicle- 
specific info and VEVI generic info, as well as dealing 
with information delivery. 

• Modules communicating and operating of the backbone 

1 . Logical representation of the system as a whole, 
including the different nodes hanging off the back- 
bone (see Fig. 1) 
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4. Implementation 

4.1 Introduction 

Since SYNERGY is by definition an evolving architecture, it 
is difficult to represent a general configuration. However, we 
will in the next paragraphs refer to one fairly simple and 
coherent application, with its proper configuration. SYN- 
ERGY, however, can be extended and modified, and is not 
limited to the example presented herein. 

Several main elements can be found in any implementation 


of SYNERGY: 

• VEVIs (rendering nodes), or nodes which provide 3D 
interactive graphics. 

• CommTasks which take care of communications between 
VEVIs and the rest of SYNERGY 

• Special purpose nodes, which represent any particular 
computing process (simulators, planners, etc.), generally 
located on machines dedicated to those processes. 

• Vehicle nodes, which are the symbolic representation of a 
vehicle, seen from the rest of SYNERGY (through the on- 
board controller). 



Fig. 1: SYNERGY: overall communication layout. 
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• Communications, to link all the nodes. 

• Platforms. All nodes can run on different platforms. 

4.2 VEVIs 

4.2.1. Description 

When referring to the overall system, we call VEVI a “ren- 
dering node". Its main purpose is to give an interactive 3D 
representation of a Virtual Environment to a user, through 
multiple input and output devices. 

Multiple VEVIs can exist at the same time in SYNERGY, 
representing for each user chosen information. It is then pos- 
sible to have several people share an environment and obtain 
informations at the same time. Each user can focus on his 
primary zone of attention, by acting on the sensors and com- 
mands at his/her disposition. 

It is important to understand that VEVI can be used as a sim- 
ulation system, bringing recorded data into a realistic 3D 
interactive universe with which the user can interact, or as a 
“3D window" displaying the current state of multiple com- 
plex systems as they operate in a remote environment. The 
difference between those two situations is simply based on 
the existence or not of real-time data sent from the systems 
on SYNERGY. 

4.2.2. Structure 

VEVI follows an object-oriented approach. Within its main 



Fig. 2: VEVI & CommTask: objects , message flows 


kernel, each entity of the world, represented or not in the Vir- 
tual Environment, exists as an object loaded from a configu- 
ration file. 

Objects communicate between each other with messages, 
which can contain data. All interactions between objects are 
defined by message passing, creating a stateless system (see 

Fig. 2). 

4.2.3. VCF file format 

Description 

The VEVI Configuration File format was designed to allow 
the full definition of objects present in the environment in a 
file read at initialization. Advantages are the added flexibility 
of being able to change this file, rather than modify the 
source code and re-compile. 

In order for this concept to be useful, the configuration lan- 
guage must provide a structure that allows implementation 
of any kind of data which might be useful for the description 
of an object. 

Configuration files are preprocessed using the standard C 
preprocessor, and therefore allowing macro definition and 
multiple file inclusion. 

Structure 

The file format contains tag names followed by arguments. 
Each argument can either be a string containing data, or a 
sublevel, surrounded by brackets 

The tag names at the upper-level always refer to objects. 
Deeper levels are defined differently, depending on each 
object. 

Example 

This example describes the vcf representation of a vehicle 
with an on-board manipulator arm. 

wtk_object { 1 

name "theVehicle" 2 

filename " theVehicleModel . nf f " 3 

scale 1.0 4 

initpos { z -50.0} 5 

attach_sensor "A_Sensor" 6 

} 

manipulator { 

name " theArm" 

raff_file " theArmD-Hdescription . raf f " 7 
scale 1 . 0 
initpos { 

frame "theVehicle" 8 
x 75.0 y 6.0 z 0.0 
ex -90.0 ez 180.0 9 

} 

father "theVehicle" 10 
attach_sensor "Another_Sensor " 

} 

1 . Type of object. 

2. Name of this instance. 
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3. File that contains the geometric data. 

4. Scaling factor. 

5. Initial position. If not mentioned, the reference frame is 
the World frame. 

6. We attach a sensor, defined by the name of the created 
object. 

7. For manipulator arms, file containing all the parameters 
necessary for its creation. 

8. In initpos, allows the specify any pose with respect to the 
frame of any other defined object of the environment. 

9. Orientations can be specified as quaternions, or as fixed 
(XYZ) angles (equivalent to Euler ZYX). 

10. Establishes a hierarchy. The named object becomes the 
father of the current one. 

4.2.4. Objects 

Definition 

Each instance of an object is defined as a data structure. The 
data of each object is private and can be accessed by the 
object alone. It contains a private data area, which is defined 
when creating the object library, and pointers to functions 
used at creation, to handle messages, and to destroy the 
object (see Fig. 3). 

Creation 

At creation time, the private data area is created, the vcf 
entry containing the description of the object is processed 
and initializations are performed. 

Handlers 

Handlers define the behavior of an object when receiving 
messages. Upon receival of a message, the called object will 
invoke its “handle” function, which will interpret the mes- 
sage, its data, and generate predefined action. Finally, a sta- 
tus message is send back to the originator. 

Destruction 

The destructor handles mainly memory issues, and clean-up 
of any data used by the object. 

Messages 

Messages can contain complex data, that is processed upon 
receipt. Each message is composed of an ID, and optionally 
some data. 

Message in this implementation are blocking, which means 



that the remaining processes will be executed only upon 
receipt of execution of the message sent. 

4.2.5. Examples 

Here are some of the currently implemented objects: 

“ Function Groups” 

In order to achieve a degree of loose synchronism, a particu- 
lar object, called a “function group”, had been implemented. 
They have the capability of containing other objects, to 
which they send predefined messages each time they are 
themselves invoked. Function groups can loop. 

“ Graphical object” 

Defines every 3D representation of objects in the universe. 
Based on CAD description, those geometric objects have 
multiple parameters that can be modified through messages 
(position, orientation, color, scale, hierarchy, etc.). Complex 
mechanisms can be created by assembling multiple objects 
and assigning hierarchy relationships. 

“ Terrain” 

Since most of our missions involve operation on a priori 
unknown terrain, we felt a need for the creation of a terrain 
object. Based on a height-field description of the terrain, we 
can represent it in the environment. 

Using sensory readings received from a vehicle, we are able 
to create a terrain object which will represent exactly the 
sensed terrain and provide an intuitive interface for the user 
to analyze its features. 

“ Viewpoint ” 

Viewpoint objects represent cameras, through which the user 
can look. Multiple viewpoints can be present within one 
environment, assigned eventually to several windows. View- 
points can have behaviors defined that lock them looking at a 
particular object, or in a certain direction. Sensors can also 
be attached to viewpoint to allow the user to look- around 
interactively. 

"Manipulator arm” 

Other interesting feature, manipulator arm objects allow 
construction and representation of complex serial manipula- 
tor arms, based on a modified Denavit-Hartenberg definition 
of their parameters [11,12], as well as models composing 
each of their parts. Once a manipulator object is created, it is 
possible to attach a sensor to it, and manipulate the arm’s 
end-effector intuitively, using a sensor. 

A manipulator object can also receive an outside telemetry 
stream which will make it represent the current joint configu- 
ration of the arm aboard a vehicle. 

“ Keyboard ” 

A keyboard object links a key to an output message and des- 
tination. As a user presses a key, the corresponding message 
is send to its destination, triggering some action. 

Keyboard mapping can be easily modified simply by chang- 
ing the binding description in the VCF (VEVI Configuration 
File) file. 


Fig. 3: Structure of an object 
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“Renderer” 

This object, which is mandatory in most cases, takes care of 
the actual rendering of the scene. Currently, all our work has 
been developed using WoldToolKit, from Sense8 Corp, Sau- 
salito. However, it is important to notice that this object can 
be interchanged for any other renderer if the need was felt. In 
particular, this might be an interesting approach for plat- 
forms not supported by actual versions of WTK, or in the 
case where this product is not available anymore. 

“ CommTask ” 

When VEVI is running in conjunction with complex systems 
on SYNERGY, the CommTask object is mandatory. It is 
responsible for the transactions between the CommTask pro- 
cess, running as a separate process and VEVI. This object 
pulls the information made available by the CommTask pro- 
cess and updates the objects affected in the Virtual Environ- 
ment. 

In cases where VEVI is used to display a simulation of the 
environment, without any interaction with the rest of SYN- 
ERGY, CommTask is not necessary. 

4.3 CommTask 

The CommTask process is an important part of SYNERGY 
It was designed and implemented to respond to several 
needs. 

a) In complex systems with multiple producers of data, and 
in the absence of tightly-synchronized processes, it is almost 
impossible to avoid differences in data rates. This has for 
consequence to create data accumulation and, if not pro- 
cessed properly, dangerous queuing of information. This is 
simply due to the fact that a consumer might not be able to 
receive the data and dispose of it in time before a new update 
arrives. 

In our situation, the main consumer of data, VEVI (rendering 
node), will typically be running at rates close to 10 Hz, 
which would place us at risk of encountering a data accumu- 
lation situation very easily. 

b) Since a user might not always be able to run VEVI on a 
machine with access to the IP backbone, it is necessary to 
provide an interface process that will communicate between 
them with alternate protocols. In most cases, we will use a 
shared memory connection to transfer data, but we can also 
use a serial connection. 

c) We also don’t want VEVI to worry about sorting through 
the masses of messages circulating to find out which ones are 
interesting to the user. A separate process, dedicated to this 
task can therefore take care of this task. Also, it will permit 
to define the number of messages passed at each request, and 
make the distinction and accounting of data types. 

4.4 Nodes 

Due to the architecture of SYNERGY, it is possible to imple- 
ment multiple communicating nodes. Each one of those node 
has a particular function, and understands certain messages. 


When new capabilities are expected, or in a case where some 
new tool is developed, one can add a node to the backbone, 
and simply define a message flow that will use the new node 
to process data from the environment. This approach allows 
the system not to be limited by present performance and 
tools. 

Also, different nodes can be executed on different CPUs, for 
peak performance. The resulting latency might become a 
problem for certain applications, but in most cases, we are 
dealing with asynchronous processes and latency is not a 
handicap. If we need to avoid latency, we will try to group 
processes that linked tighter synchronism in order to reduce 
delays. 

Since the system is stateless, it is possible to replace nodes 
and interchange them. Also, in some cases, a missing node 
will simply remove some extended capability but won’t pre- 
vent the execution of the experiment. Each node has its own 
development curve, and the evolution of the whole is created 
by simultaneous evolution of each one of its parts, but isn t 
held back by one of them in particular. 

In cases where several processes use the same algorithms, 
this approach allows to maintain uniqueness of data and 
reproducibility of data, since a unique process will deliver 
results to any consumer that requires it. 

4.4.1. Vehicles 

A vehicle can be considered as a node, since it processes 
data and broadcasts information about its state to any inter- 
ested party within SYNERGY The different sub-systems of 
a vehicle can be implemented as different nodes, each one of 
them hanging of the backbone, or as parts of the main pro- 
cess. Difference in the implementation have to be deter- 
mined from case to case. 

4.4.2. Special purpose nodes 

Simulators 

Simulators are frequent nodes that one might want to imple- 
ment on SYNERGY. For example, in the case of a kinemat- 
ics simulator: a user, in the environment is controlling an 
arm by guiding its end-effector. Depending on whether or 
not we want to have the real arm reflect the user s command, 
we can direct messages to a simulator or to the real arm. In 
the first case, when the simulator receives a vector of 
motions in the cartesian space, it translates it into joint veloc- 
ities, which are returned the virtual representation of the arm 
for update. 

In the latter case, the vector would be sent directly to the arm 
controller, which then would use the same simulator to gen- 
erate joint velocities for the real arm. 

Depending on the availability, or the appropriateness of 
using the real arm, we have the system behave in two differ- 
ent ways, yet it is transparent to the user 
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Fig. 4: Dataflow in SYNERGY with a simulator node. 
First, the communication is established between the virtual 
representation of an arm and the kinematic model. Then , the 
real arm uses the same kinematic model to reproduce com- 
mands sent from the simulation. 


Translators 

In some cases, it might be necessary to translate data coming 
from a node before sending it to another. A translator node 
could achieve this, and allow to maintain the current struc- 
ture of both the provider and the consumer of data. 

Renderer 

Some complex computations might be necessary in order to 
create better representation of the data. For this purpose, we 
have nodes which execute as a task on a separate machine to 
create photo-realistic views of the data gathered. Since this is 
a time-consuming activities, those nodes are generally 
routed to high-performance machines on a remote site. 


5. Applications 

We will shortly present some of the vehicles controlled using 
the described architecture. In all those cases, the virtual 
equivalent of a real vehicle was updated by telemetry 
updates received through SYNERGY. 


5.1 MEL 

The Mobile Exploration Landrover (MEL) has been under 
development since July 1992. The vehicle has two indepen- 
dent drive wheels and a variety of sensing devices (differen- 
tial GPS, magnetic compass, I.R. sensor, ultrasonic sensors, 
stereo pan/tilt cameras, etc.), as well as a wireless Ethernet 
for communications with SYNERGY. 



Fig. 5: MEL in the virtual world. 



Fig. 6: The real MEL, with the arm, sensors and a pan/tilt ste- 
reo camera. 
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5.2 TROV 

At the end of 1993, TROV (Telepresence Remotely Oper- 
ated Vehicle) was deployed under the sea ice near McMurdo 
Science Station, Antarctica and teleoperated from a control 
station located at NASA Ames, California, as well as several 
other locations in the country. Antarctica, like Mars, has 
remote and hostile locations that are difficult for humans to 
explore. The purposes of this mission were to explore below 
the surface of McMurdo; conduct a benthic ecology survey; 
perform a study of human teleoperation performance and 
demonstrate virtual environments based teleoperation tech- 
niques [7,8]. 



Fig. 7: TROV in the virtual world. 


5.3 Dante 

Dante, a frame walker robot, was sent into Mt Spurr, in 
Alaska in July 1994. It was controlled via satellite and Inter- 
net connections by a team with representatives from NASA, 
Carnegie Mellon, the Alaskan Volcano Observatory, and 
other government, university and private organization [10]. 



Fig. 9: Dante in the virtual environment. Along with informa- 
tion about the forces and torques on the limbs and the tether, 
terrain maps went scanned using Dante 's on-board laser 
scanner, and shipped through the Internet to be displayed in 
the virtual world. Based on this information, operators of the 
vehicle could take better routing decisions, based on the con- 
figuration of the terrain. 



Fig. 8: TROV under the ice in the Antarctica 


Fig. 10: The real Dante on a transition. 
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5.4 Marsokhod 

Originally designed in Russia to do inspection on the site of 
Tchemobyl, Marsokhod (Mars Walker in russian) is an artic- 
ulated 6-wheeled rover. Its excellent capacities on rugged 
terrains made it an ideal candidate for future planetary mis- 
sions. It is anticipated that one of those rovers will be sent to 
Mars sometime around 1998. 


5.5 Ranger 

Ranger is a free-flying satellite servicing robot. It has two 7- 
dof manipulator arms, a camera arm and a grapple arm. This 
vehicle is currently developed by the University of Mary- 
land, Space Systems Laboratory. We will provide an alter- 
nate control interface for the visualization of scientific and 
telemetry data, as well as a fully-immersive operator inter- 
face using VEVI. 



Fig. II: Marsokhod in VEVI. Terrains created from real virtual Ranger in its current development stage. 

data, as well as texture maps contribute greatly to the realism F 

of a scene. 



Fig. 14: A view of a rendered image of a fully equipped Rang- 
er. Notice the camera arm, and the stowed grappling arm. 


Fig. 12: The real Marsokhod. 
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6. Conclusion 

This paper presents an overview of VEVI as well as the com- 
plete networking concept SYNERGY. Version 3.0 is cur- 
rently under development and more capabilities should be 
added to it in the next months. 

So far, VEVI 3.0 has reached our expectations. The configu- 
ration file approach has permitted rapid prototyping and 
implementation of various environments, without showing 
any major limitation. Detailed benchmark haven t been per- 
formed so far, but a performance loss, which could be 
expected because of the extension of generality, hasn’t been 
yet demonstrated. 

Further reference and information, consult our WWW 
server: http://maas-neotek.arc.nasa.gov 
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